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@ Interexchange carriers make their rate infor- 
mation for long-distance sen/ice available in a 
database (16). PBXs (40) and telephone central 
offices (31) access that rate infonmation using 
ISDN and/or 387 signaling and use it as a basis 
for detennining which carrier to use at any 
given time in the routing of a call. Such acces- 
sing may be carried out on a call-by-call basis. 
Or a carrier's schedule of rates can be stored 
locally in the PBX or local switching office, 
thereby obviating the need for a database query 
for every call. 
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Background of the Invention 

The present invention relates to telecommunica- 
tions. 

Increasing competition in the provision of tele- 
communications services is a world-wide trend. 
Competition is evolving to the point that many tele- 
communications services can be obtained from a 
range of telecommunications service providers. This 
includes both services provided to consumers, such 
as basic long-distance service, and business-orient- 
ed services, such as sophisticated outbound calling 
programs. Moreover, the existence of competition 
among the various service providers has had the ef- 
fect of subjecting the rates charged for telecommuni- 
cations services to the forces of the marketplace, 
rather than being set by regulatory mandate. 

Summary of the Invention 

it has now been realized that technologies that 
are currently available today can be harnessed to 
further extend the concept of free-market pricing for 
telecommunications services - particularly the per- 
call rates charged for telephone calls. In accordance 
with the invention, a telecommunications service pro- 
vider, such as an interexchange carrier, makes its 
rate information for at least one service - such as ba- 
sic long-distance service - available in a database. 
That information is updated on an ongoing basis in re- 
sponse to such "rate-controlling" data as the current 
levels of traffic within the various portions of the ser- 
vice provider's network; observed trends in those lev- 
els over time; or rates currently offered by other ser- 
vice providers. Given the availability of such a data- 
base in accordance with the invention, switching 
equipment which originates subscribers' calls - such 
as a PBX or central office - can obtain the rate infor- 
mation stored therein and use it as a basis for deter- 
mining which provider to use at any given time. The 
invention is advantageous for the service providers in 
that they can, for example, match their rate schedules 
to take advantage of unique calling patterns that may 
develop in the course of a day; or stimulate or dis- 
courage traffic in particular parts of their networks to 
match demand with capacities. They can also use it 
to take into account rate changes initiated by other 
service providers. The invention is advantageous for 
subscribers because it allows them to "shop" for the 
lowest possible rates. 

Brief Description of the Drawings 

The invention may be more fully understood from 
a consideration of the following detailed description 
of various illustrative embodiments shown in the 
drawings. The FIGS, of the drawings, more particu- 
larly, are as follows: 



FIG. 1 depicts an illustrative telecommunications 
network in which the invention is implemented; 
FIGS. 2-5 are flowcharts showing steps carried 
out within the network of FIG. 1 to implement va- 
5 rious embodiments of the invention; and 

FIG. 6 is a flowchart showing steps carried out 
within the network of FIG. 1 to update toll rates 
stored in a rate database within the network. 

10 Detailed Description 

FIG. 1 shows a telecommunications network in 
which the invention is implemented. The network il- 
lustratively includes three interconnected telecom- 

15 muntcations service providers' networks: local ex- 
change carrier (LEG) network 30 and interexchange 
carrier (iXC) networks 10 and 20. These three net- 
works all provide services to subscribers associated 
with station sets 35-1 through 35-N connected to cen- 

20 tral office 31 within LEG network 30. 

IXC networks 10 and 20 have the same basic 
structure. Accordingly, only one - IXC network 10 - is 
shown in detail. In particular, network 10 includes a 
plurality of toll switch complexes, three of which are 

25 shown in the FIG. - namely complexes 11,12 and 13, 
which are interconnected via interoffice trunks 115, 
116 and 125. Atoll switch complex typically serves a 
number of LEC central offices, and in this case it is 
toll switch complex 13 that serves cerftral office 31 

30 via voice path 1 39. 

SS7 signaling between central office 31 and IXC 
network 10 is carried out by way of link 32 and signal 
transfer point (STP) 35 connecting to STP 15 within 
network 10 via link 34. In general, network 10 will 

35 have a number of STPs and STP 35 could, alterna- 
tively, be connected to an STP other than STP 15. 
Each of the STPs is, in actuality, a pair of STP units. 
This provides each STP installation with load-sharing 
and backup capabilities. Thus the links shown in FIG. 

40 1 as being connected to an STP are, in actuality, div- 
ided between the two STP units of an STP pair. Net- 
work 10 further includes a signaling control point, or 
SCR 17. This is, in essence, a database, to which 
queries are directed from within network 10 to obtain, 

45 for example, routing information for "800" and "900" 
type calls and authorization codes for virtual private 
network (VPN)-type calling. 

Also shown in FiG. 1 is a PBX 40 located on a 
subscriber's premises serving station sets such as 

50 Station sets 45-1 through 45-M. PBX 40 is intercon- 
nected with central office 31 and network 10 via re- 
spective ISDN PRI, signaling links. In particular, B 
channels 43 and D channels 42 extend to central of- 
fice 31, while B channels 48 and D channels 49 ex- 

55 tend to switch complex 12. 

Each of the toll switch complexes comprises a 
"host" toll switch and an SS7 signaling interface. Toll 
switch complex 11, in particular, includes toll switch 
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111 serving as host The SS7 signaling interface is 
connmon network Interface (CNI) ring 112 described, 
for example, in U.S. Patent 4.752,924 issued June 21 , 
1988 to J. W. Darnell et al. Toll switch 111 connects 
to CNI ring 112 via path 113. Although not explicitly 
shown in the FIG,, path 113 illustratively includes an 
intermediary processor which controls the passage 
of information between the switch and the CNI ring. 

Toll switch complexes 12 and 13 are configured 
similarly. In particular, complex 12 (13) includes toll 
switch 121(131) serving as host for CNI ring 122 
(132). Toll switch 121 (131) substantially identical to 
toll switch 111 and connects to CNI ring 122 (132) via 
path 123(133). 

SS7 signaling among various ones of the net- 
work elements just described is provided over a num- 
ber of SS7 links. In particular, CNI ring 112 has an 
SS7 connection to STP 15 via link 117. Simitar SS7 
connections are provided for CNI rings 122 and 132 
via links 1 27 and 1 37, respectively. Finally, a CNI ring 
(not shown) within SCP 1 7 is connected to STP 1 5 via 
link 171. 

Also included within IXC network 10 is network 
monitor and control system 18, which is discussed at 
a more opportune point hereinbelow. 

Central office 31 interconnects with IXC network 
20 via voice path 39. It also has an SS7 connection 
to network 20 via SS7 link 32, STP 35 and SS7 link 
36. Additionally, PBX 40 is connected to IXC network 
20 via ISDN PRI B channels 46 and PRI D channels 
47. 

In the operation of the network of FIG. 1 , a major 
function of the signaling carried out over the SS7 
links is to allow two network elements to be correctly 
connected. !n this process, the SS7 signaling may re- 
late to such functionalities as circuit set-up/tear-down 
and database (e.g.. SCP) lookup in order to imple- 
ment, for example, number translation for "800" ser- 
vice. The SS7 signaling capability is also used to an- 
other purpose. Specifically, at least one of the IXC 
networks makes its rate information for at least one 
service - such as basic long-distance service - avail- 
able in a database. In this embodiment, more specif- 
ically, IXC network 10 maintains the rate database 16 
in which its rates for long-distance service are main- 
tained. Illustratively, IXC network 20 maintains a sim- 
ilar database, although, as will be discussed in fur- 
ther detail below, this is not required. 

Illustratively, both PBX 40 and central office 31 
access the rate information in rate database 16 and 
in the rate database maintained by IXC network 20. 
That rate information is then used as a basis for de- 
termining, at any particular time, which of the two 
IXCs a particular call is to be routed to. That determi- 
nation, in this example, is based simply on which one 
of the two IXCs is offering the lower rate at the time, 
although it could take into account other factors such 
as the existence of discount plans offered by the va- 



rious service providers. 

In the case of the PBX, the choice of IXC is made 
within the PBX and the call is routed to the selected 
IXC via the PBX's direct connection thereto. In the 

5 case of central office 31, it is assumed that the local 
exchange carrier which operates that central office 
offers a "lowest-cost call", or LCC, service to its sut>- 
scribers wherein the subscriber's local switching of- 
fice determines the lowest-cost interexchange carrier 

10 for a dialed call and automatically routes the call to 
that carrier. 

It may not be determinable in the first instance 
which IXC is the lowest-cost provider. For example, 
one carrier may have the lower initial-period charge 

15 while the other has the lower per- minute-thereafter 
charge. In such situations, some predetermined 
methodology can be used to make a decision as to 
which carrier to use. For example, the decision could 
simply be based on the average length of all interex- 

20 change calls; or on a generalized model of call dura- 
tions between the geographical locations in question; 
or on statistical information about call durations from 
the particular station set in question, either generally 
or to the specific dialed location. The existence of 

25 special billing plans offered by service providers for 
which particular subscribers may be signed up could 
also be taken into account in making a carrier choice. 
If the rates offered by the two carriers are the same, 
or if a lowest-cost provider for a call is otherwise not 

30 able to be identified, the call can simply be routed to 
a pre-identif ied default provider, currently referred to 
in the United States telecommunications industry as 
the "primary interexchange carrier", or PIC. 

Rate database 16 is accessed via STP 15 and 

35 SS7 link 161 using standard network database ac- 
cess mechanisms. In particular, central office 31 can 
access rate database 16 using nothing more than a 
standard SS7 TCAP messaging to extract the desired 
information. PBX 40 could similarly query rate data- 

40 base 1 6 if it had an SS7 link to an STP. Indeed, certain 
large business customers' PBXs already have SS7 
links in place in order to communicate with SCPs to, 
for example, avail themselves of so-called intelligent 
call processing (ICP) services. In the present em bod i- 

45 ment, however, PBX 40 is not provisioned with SS7 
signaling capabilities. Rather, its access to the rate 
databases of the two IXC networks is via its ISDN 
connections thereto. Here, again, standard techni- 
ques can be used; it is already known how to provision 

50 PBXs with the capability of accessing network data- 
bases such as SCP 17 for ICP using ISDN signaling 
as described in further detail below. 

The accessing of rate database 16 could be on a 
call-by-call basis. That is, whenever a subscriber at, 

55 for example, station set 35-1 connected to central of- 
fice 31, or at station set 45-1 connected to PBX 40, 
enters the digits of a telephone number, the central 
office or PBX launches a query to the various IXC 
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networks to obtain the current rate information for the 
call in question. Alternatively, a carrier's entire 
schedule of long-distance rates applicable to calls 
originating from the PBX or central office in question 
could be accessed periodically - for example, every 
quarter-hour - and stored locally in the PBX or central 
office, thereby obviating the need for a database 
query for every call. 

Advantageously, the LECs and IXCs could estab- 
lish a protocol whereby rate changes are made avail- 
able within the rate database sufficiently in advance 
of when they are effective so as to allow the LEG to 
be sure that it is always in possession of the current 
rates. For example, it could be arranged that rate 
changes will be made available no later than 10, 25, 
40 and 55 minutes past the hour, to be effective ex- 
actly five minutes later, i.e., on the quarter-hour. An- 
other possibility is to avoid the need for the LECs or 
central offices to repeatedly access the IXCs' rate 
databases by having the IXCs automatically transmit 
their rate information to the central offices either per- 
iodically or whenever there is a change in the rates 
that apply to calls originating from that LEC or central 
office. 

Alternatively, instead of each central office re- 
ceiving the rate schedule information from the ser- 
vice providers directly, that information could be ob- 
tained by the LEC - either in response to a query or 
via automatic transmission from the service provid- 
ers. The LEC, in turn, could either a) distribute the 
rate schedule to all of the central offices which the 
LEC controls or b) provide a LEC database to which 
each central office which the LEC controls could 
launch a query. The latter approach may be particu- 
larly advantageous in that the LEC database could 
precompare the rates offered by the various service 
providers and could determine and store information 
indicating which carrier offered the lowest rate to, for 
example, each possible destination central office in 
the overall network using, if desired, one or more of 
the statistical call models discussed above. A central 
office could then determine which provider a call is to 
be routed to by simply querying the central LEC da- 
tabase, supplying in the query the destination area 
code and local exchange code. 

Moreover, if a particular service provider chose 
not to maintain a rate database, its fixed, published 
rates could nonetheless be stored locally and com- 
pared with the changing rates offered by providers 
who do. 

Various of the possibilities mentioned above are 
illustrated in the flowcharts of FIGS. 2-5. 

FIG. 2, in particular, is the PBX example descri- 
bed above. A caller at one of station sets 45-1 dials 
the telephone number of a called party (action block 
201 ). PBX 40 thereupon determines whether this is a 
call for which the rate is to be checked. If it is not - as 
would be the case, for example, if the call were being 



made within the local calling area of the PBX - the call 
is completed normally (action block 204). If, however, 
the rate is to be checked, PBX 40 launches queries, 
in parallel, to IXCs 10 and 20. 

5 With respect, in particular, to IXC 10, PBX 40 

launches (action block 206) an ISDN set-up request 
with a Q.932 facility information element (FIE). This 
request contains within it the information needed to 
determine what the applicable rate for the call wilt be. 

10 Such information would include, for example, the call- 
ing and called telephone number area code and local 
exchange. The request is forwarded to toll switch 121 
via D channels 49, CNI ring 122 and link 123. Switch 
1 21 thereupon converts the Q.932 into an SS7 TCAP 

15 BEGIN message (action block 209), and thereupon 
sends that message to rate database 16 using global 
title translation via link 123, CNI ring 122, SS7 link 
127, STP 15 and SS7 link 161 (action block 213), 
Rate database 16 performs a lookup and returns the 

20 rate (action block 213). Rate database 16 performs a 
lookup and, again using global title translation, re- 
turns the rate data to switch 121 in a TCAP END mes- 
sage (action block 216). (As is well known, toll call 
rates are typically defined by geographical distances 

25 between termination points and the aforementioned 
lookup may therefore include some simple computa- 
tions to determine the rate.) Switch 121 converts the 
TCAP END message to a Q.932 FIE which it sends to 
PBX 40 (action block 218). 

30 At the same time as action blocks 206 through 

218 are being carried out within IXC 10, a similar set 
of action blocks - denoted generically at 220 - is being 
carried out within IXC 20. Ultimately, PBX 40 has 
available to it the rates to be charged for the call in 

35 question by each of the two IXCs. It compares them, 
selects a carrier based on the comparison and then 
places the call to the selected carrier via the appro- 
priate PRI link (action block 219). 

The steps of FIG. 3 illustrate the accessing of the 

40 rate database by LEC 30 to provide a "lowest-cost 
calling" service to subscribers who may wish to have 
this service. The subscriber (customer), such as a 
subscriber using station set 35-1 , places a call to cen- 
tral office 31 (action block 301). The latter determi- 

45 nes from an internal database (not shown) whether 
the subscriber in question has subscribed to the low- 
est-cost calling service (action block 304). If not, the 
call is routed to the subscriber's pre-selected primary 
Interexchange carrier (action block 305). If yes, the 

50 central office launches queries, in parallel, to IXCs 10 
and 20, as was the case for PBX 40 described above. 
Since central office 31 has direct SS7 links to the 
IXCs' rate databases, ISDN signaling is not involved 
in this case. Rather, the central office launches an ap- 

55 propriate SS7 TCAP BEGIN message to rate data- 
base 16 (in the case of IXC 10) via SS7 link 32, STP 
35. SS7 link 34, STP 15, and SS7 link 161. The rate 
database performs the operations described earlier 
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in conjunction with FIG. 2 and provides the desired 
data to central office 31 in a TCAP END message. 

At the same time as action blocks 306 and 309 
are being carried out within IXCIO. a si mi tar set of ac- 
tion blocks - denoted generically at 330 - is being car- 
ried out within IXC 20. Ultimately, central office 31 
has available to it the rates to be charged for the call 
in question by each of the two IXCs, As before, it com- 
pares them, selects a carrier based on the compari- 
son and then places the call to the selected carrier 
(action block 311). 

As noted earlier, an alternative to making a rate 
database query for each call is to periodically - for ex- 
ample, every quarter-hour - access a carrier's entire 
schedule of long-distance rates and store them local- 
ly. This approach is illustrated in FIGS. 4 and 5, again 
in the context of a lowest-cost calling service offered 
by a LEG. 

Action blocks 401 and 402 in FIG. 4 represent a 
process whereby central office 31 periodically re- 
ceives from IXCs - via any of the mechanisms descri- 
bed above - the entire rate schedule applicable to 
calls routed from that central office via those IXCs. It 
initiates the process with a TCAP BEGIN message. 
Because the return information is fairly lengthy, it 
cannot be contained in a single TCAP END message. 
Rather, an IXC returns the rate schedule in a se- 
quence of TCAP CONTINUE messages terminated 
by a TCAP END mesage. 

FIG. 5 shows the implementation of the lowest- 
cost calling service using this approach. In particular, 
action blocks 504, 506 and 508 are the same as ac- 
tion blocks 301, 304 and 305, respectively, of FIG. 3, 
At action block 511, however, a further service is of- 
fered to the subscriber. Specifically, it is postulated 
that an IXC may be willing to specify the rates that will 
be effective throughout some future time period, 
such as half an hour Having retrieved those rates 
from the IXC's rate database, the central office can 
thereupon scan the rates that will be in effect through- 
out that future time period (action block 511). If there 
would be no benefit in waiting, because none of the 
IXCs will be offering a lower rate than the lowest rate 
currently available, then the call is routed to the low- 
est-cost carrier (action block 516). If there would be 
a benefit, then an announcement is presented to the 
caller (action block 514) informing him/her of the rel- 
evant facts, such as when the rate change will be- 
come effective and what the monetary benefit in wait- 
ing will be. The caller is prompted to indicate whether 
the call should be placed now or not (decision block 
517). If yes, the call is placed (action block516). If no, 
the call is disconnected (action block 518). In the 
event that the caller wishes to wait until a lower rate 
is available, the LEC can provide the further service 
of offering to automatically place the call when the 
new, lower rate becomes effective. Specifically, at 
the point in time that the new rate becomes effective. 



the central office would ring the originating telephone 
line. Upon the station set being taken off hook, it 
would proceed to connect it to the called party with, 
perhaps, an announcement being first provided to the 

5 originating station indicating that this was the call that 
had been re-scheduled pending the lower rate be- 
coming effective. 

We turn, now, to a discussion of how the rate 
schedules in rate database 16 are illustratively updat- 

10 ed. 

As noted earlier, IXC network 10 includes net- 
work monitor and control system 18. System 18 may 
comprise one or a plurality of so-called operations 
support systems. As is well known, such systems 
15 communicate with, for example, toll switch com- 
plexes, STPs, SCPs, transmission facilities and other 
network elements in order to monitor such factors as 
levels of traffic within various portions of the network 
and - based on the data thus obtained - to control, for 

20 example, the routing of traffic within the network and 
the issuing of alarms to network management per- 
sonnel. System 18 communicates with the various 
network elements that it monitors and controls using 
BX.25 and OSI protocols. The communication is car- 

25 ried out by way of a switched digital network and/or 
direct (point-to-point) connections. For example, di- 
rect connections may be used to interconnect system 
1 8 with the toll switches, with the digital network con- 
nection being used as a backup. With the exception 

30 of rate database 1 6, the connections between system 
18 and the other network elements are illustratively 
via the digital network only, with no backup. In FIG. 
1 , path 181 is representative of the links interconnect- 
ing system 18 with the switched digital network. Sig- 

35 naling paths 1 82 are representative of the aforemen- 
tioned direct connections. As just alluded to, there 
does exist a direct connection between system 18 
and rate database 16, that being via a specific one of 
paths 182 - namely path 1821, 

40 Network monitoring and control system 18 is pro- 

grammed to report to rate database 16 certain prede- 
termined rate-controlling data. In preferred embodi- 
ments, that data includes, at a minimum, the level of 
traffic at various points in the network as well as the 

45 status (active/inactive) of various particular network 
elements. The rate-controlling data is then used by 
rate database 16 to update the rate schedules. 

Rate database 16 is illustratively an active data- 
base of the type described, for example, in Dayal et 

50 al, 'The HiPAC Project: Combining Active Databases 
and Timing Constraints', 

ACM-SIGMOD Record . Vol. 17. No. 1, March 1988, 
pp. 51-70; McCarthy et al. 'The Architecture of An Ac- 
tive Database Management System'. 
55 Proc. ACM-SIGMOD 1989 Infl Conf. Management of 
Data, Portland, Oregon, May-June 1989. pp. 215- 
224; Gehani et al, 'Ode as an Active Database: Con- 
straints and Triggers', Proc. 17th Inti Conf. Very 
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Large Data Bases , Barcelona. Spain 1991, pp. 327- 
336; Gehani et al, 'Event Specification in an Active 
Object-Oriented Database', Proc. ACM-SIGMQD 
1992 Int'l Conf. on Managennent of Data , San Diego, 
California 1992; and Gehani et al. 'Connposite Event 
Specification in Active Databases: Model & Imple- 
mentation', Proc. of the 18th Int'l Conf. on Very Large 
Databases , Vancouver. BC, Canada, August 1992. 

If a conventional database were used in this ap- 
plication, a software application executing Indepen- 
dently of the database nnanager would have to be pro- 
vided to a) repetitively access the rate-controlling 
data stored in the database, b) examine it and, c) 
based on a predetermined toll rate-changing algo- 
rithm, change the toll rates stored therein. The large 
volume of data that would typically be stored in the da- 
tabase, however, could well result in the need for an 
extremely powerful, and therefore expensive, proc- 
essor on which to execute such an application. In an 
active database, by contrast, the database manager 
both a) stores data and b) generates an "alerter" or 
"trigger" - thereby initiating the taking of some action 

- when particular data meets particular pre-program- 
med criteria (Indeed, a trigger can be used to decide 
whether particular rate- control ling data, such as the 
level of traffic through a switch at any particular time 

- is sufficiently "of Interest" at this time to warrant 
storing it.) Because the data is being examined and 
acted upon as it is received, a much less powerful 
processor is required. In this case, that action is the 
updating of the toll rates. 

As an example, rate database 16 can be pro- 
grammed to reduce, by a predetermined percentage, 
the toll rate for all calls carried between a particular 
pair of toll switches if some criterion is met. Such rate 
reductions would be expected to have the effect of 
stimulating traffic along the route in question be- 
cause, at least for some calls which include that route 
as one of their legs, the toll rate can be made less than 
that offered by other service providers. The program- 
ming within rate database 16 is such that at a later 
time, when some other criterion is met. the toll rate in 
question Is returned to its original level. Indeed, it is 
possible that a rate may be increased above its typi- 
cal level should conditions warrant it. 

The criterion can be a very simple one, such as 
the crossing of a traffic level threshold (measured, for 
example, in calls- per- hour or percentage capacity) 
between the two switches. Or It can be quite complex, 
such as a criterion which takes into account traffic 
level trends involving quite a number of toll switches 
over some period of time. Other factors that could be 
used include the percentage of capacity to which a 
particular network element is loaded; the operational 
status (active/inactive) of various network elements; 
the extent to which a level of traffic differs from some 
predicted value, or combinations of these. 

It will thus be appreciated that rate database 16 



is really two databases. One stores rate controlling in- 
formation used to generate the triggers. The other 
stores the rate schedules themselves. 

Criteria other than those which relate to data pro- 

5 vided from system 18 could also be used by rate da- 
tabase 16 to change the rates. For example, triggers 
generated by database 16 may take into account toll 
rates offered by IXC network 20, that data being ob- 
tained via an SS7 query made to a rate database with- 

10 in IXC network 20. As another possibility, triggers 
may be generated as a function of the level of de- 
mand at a particular element of the network for a net- 
work-based service, such as a network-based inter- 
active game. Such data may be gotten, again via an 

15 SS7 query, from an SCP through which entry to the 
game is controlled. 

An illustrative process by which the rates stored 
in rate database 16 are updated is shown in FIG. 6. 
As indicated at action block 601, system 18 and/or 

20 Other sources of rate-controlling data provide that 
data to rate database 16. The latter, at action block 
602, updates rates based on active database triggers 
generated in response to that data. The updated rates 
are thereupon communicated to the network's billing 

25 systems, as indicated at action block 604, illustrative- 
ly in response to those same triggers. 

Considering this last function in more detail, it will 
be appreciated that the changes in toll rates within 
rate database 16 must be coordinated with the oper- 

30 ation of the billing systems (not shown) within the net- 
work. Typically, such billing systems receive billing 
records that are created by the toll switches at the 
completion of telephone calls. Ultimately each call is 
"rated" by the billing system, meaning simply that the 

35 toll charge for the call is computed based on the rates 
in effect when the call was made, and the computed 
charge Is then added to the billing record for the call. 
Here, each toll rate change made in rate database 16 
would have to be made known to those components 

40 of the overall billing infrastructure which rate the tel- 
ephone calls. This is done straightforwardly by hav- 
ing rate database 16 communicate such changes into 
the billing system, via appropriate signaling links, and 
again, in response to those same triggers, sufficient- 

45 ly in advance of the time that they would become ef- 
fective to be sure that the updated rate schedules 
would be available for the rating of calls made when 
those rates are effective. Each update would be ac- 
companied with data indicating the time at which it is 

50 to become effective. 



Claims 

55 1. A method for use by a telecommunications ser- 
vice provider which routes calls over a telecom- 
munications network (10). said method compris- 
ing the step of 
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storing, in a database (16), rate informa- 
tion defining the toll rates currently in effect for 
at least one class of calls routed over said net- 
work, said method 

CHARACTERIZED BY the step of 5 
providing, to a source of said calls (31), via 
a telecommunications signaling path (171, 15, 
34, 35, 32) connected to said database, at least 
a portion of said rate information. 

10 

2. The method of claim 1 wherein said database is 
an active database, 

3. The method of claim 1 wherein said portion of 

said rate information includes rate information 15 
applicable to calls which originate from said 
source of said calls. 

4. The method of claim 1 wherein, in said providing 
step, said portion of said rate information is pro- 20 
vided in response to a query from said source of 

said calls. 

5. The method of claim 1 comprising the further 
step of 25 

changing at least a portion of said stored 
rate information as a function of at least a first 
predetermined criterion. 

6. The method of claim 5 wherein, in said providing 30 
step, said portion of said rate information is pro- 
vided in response to the occurrence of said 
changing. 

7. The method of claim 5 wherein said criterion is a 35 
function of at least a first level of traffic within 

said network. 

8. The method of claim 5 wherein said criterion is a 
function of the operational status of at least one 40 
element of said network. 

9. The method of claim 1 comprising the further 
step of 

changing at least a portion of said stored 45 
rate information as a function of a change in rate 
information defining the toll rates currently in ef- 
fect for said class of calls routed over a telecom- 
munications network operated by a second tele- 
communications service provider. so 

10. A method for use by apparatus (31) through 
which a telephone toll call from an originating lo- 
cation to a destination location can be routed via 

a selected one of at least two service providers 55 

(10, 20). the method 

CHARACTERIZED BY the steps of 
receiving from at least a first one of the 



service providers, via a telecommunications sig- 
naling path connected to said apparatus (34, 35. 
32). the toll rate applicable for the call If routed via 
said first service provider. 

selecting a particular one of the service 
providers as a function of at least the toll rate re- 
ceived from said first service provider, and 

routing the call via the facilities of the se- 
lected service provider. 

11. The method of claim 10 wherein said receiving 
step includes the step of launching a query to said 
first service provider via said telecommunica- 
tions signaling path. 

12. The method of claim 11 wherein in said receiving 
step said apparatus receives a schedule of toll 
rates applicable to calls which are routed through 
said apparatus, said schedule including said toll 
rate applicable for said call. 

13. The method of claim 1 wherein said receiving 
step includes the step of receiving from said first 
service provider a schedule of toll rates applica- 
ble to calls which originate from said apparatus. 

1 4. The method of claim 1 3 wherein said schedule of 
toll rates is provided to said apparatus at the ini- 
tiative of said first service provider. 

15. The method of claim 1 wherein said selecting is 
a further function of the toll rate applicable for the 
call if routed by a second one of the service pro- 
viders. 

16. The method of claim 1 comprising the further 
step of receiving from a second one of the service 
providers, via a telecommunications signaling 
path, the toil rate applicable for the call if routed 
via said second service provider, and said select- 
ing is a further function of the toll rate received 
from the second service provider. 

17. The method of claim 1 wherein the selected ser- 
vice provider is the one whose toll rate for the call 
is the lowest. 
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FIG, 3 




CUSTOMER PUCES LONG DISTANCE 
CAa TO CO 

~J 



.301 



NOX LOWEST-COST \-^304 
aLQNG CUSTOMER 'I 



QUERY IXC 10 

\ — 



YES 



QUERY IXC 20 



CO SENDS SS7 TCAP BEGIN 
MESSAGE TO RATE DATBASE 



I 



1 



RATE DATABASE PERFORMS 
TABLE LOOKUP AND RETURNS 
DATA TO CO IN A 
TCAP END MESSAGE 



.306 



,309 



1^330 



CO PUCES CALL WITH 
LOWEST-COST CARRIER 



Jit 



FIG. 4 



CO PERIODICALLY REQUESTS RATE 
SCHEDULES FROM PARnCIPAHNG 
CARRIERS USING TCAP BEGIN MESSAGE 



I 



.401 



COJCOYES TCAP CONHNUE AND TCAP END 
MESSAGES CONTAINI NG RATE SCHEDULES 

I 



,403 



10 



EP 0 608 066 A2 



FIG. 5 
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FIG. 6 
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i Interexchange carriers make their rate infor- 
mation for long-distance service available in a 
database (16). PBXs (40) and telephone central 
offices (31) access that rate infonnation using 
ISDN and/or 887 signaling and use it as a basis 
for detemnining which carrier to use at any 
given time in the routing of a call. Such acces- 
sing may be carried out on a call-by-call basis. 
Or a carrier's schedule of rates can be stored 
locally in the PBX or local switching office, 
thereby obviating the need for a database query 
for every call. 
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